gh-142518: Annotate PyDict_* C APIs for thread safety#145875
gh-142518: Annotate PyDict_* C APIs for thread safety#145875lysnikolaou wants to merge 4 commits intopython:mainfrom
Conversation
|
|
||
| The operation is atomic in the :term:`free-threaded build`, if *key* | ||
| is a builtin type (e.g. :class:`str`, :class:`int`, :class:`float`) or any | ||
| other object which does not define :meth:`~object.__hash__` and :meth:`~object.__eq__` methods. |
There was a problem hiding this comment.
Don't most objects have __hash__ and __eq__?
What's the real requirement here? If I define a built-in type, what property do its tp_hash/tp_richcompare need to have to keep this atomic?
There was a problem hiding this comment.
Don't most objects have hash and eq?
They have but it is inherited from object, here the docs mean user-defined methods which override it.
What's the real requirement here? If I define a built-in type, what property do its tp_hash/tp_richcompare need to have to keep this atomic?
The real requirements are the function should not call back into Python or the C-API and not release the thread state. All of this is implementation defined and subject to change hence it is not documented.
There was a problem hiding this comment.
The way this is written guarantees that all built-in types have this property.
But, tuple or frozendict don't, and for some others I'd consider it an implementation detail.
How do I tell whether we guarantee that a given type doesn't release thread state in __eq__/__hash__? It's easy for str/int/float, but there's a lot of other built-in types.
There was a problem hiding this comment.
The way this is written guarantees that all built-in types have this property.
But, tuple or frozendict don't, and for some others I'd consider it an implementation detail.
It happens transitively, if tuple contains simple types such as ints and strs, it is atomic.
4 participants
📚 Documentation preview 📚: https://cpython-previews--145875.org.readthedocs.build/